\section{Risikostyring} 

\textit{I følgende afsnit vil vi forklare formålet med risikostyring og hvordan det kan bruges.
Vi vil blandt andet vise hvordan vi har udført en risikoanalyse samt risikovurdering af vores projekt.
}
\\\\
I IS-projekter lignende vores, kan selv små risici have store omkostninger for projektets fremgang. For at mindske omkostningerne og forebygge uhensigtsmæssige forsinkelser kan man foretage en risikoanalyse. Formålet er at identificere mulige risici så tidligt i projektforløbet som muligt, med henblik på at finde ud af hvor stor en effekt risikoen har, hvordan man kan forhindre risikoen i at opstå, hvordan man kan overvåge den, og skulle risikoen være uundgåelig, hvordan man kan kontrollere skaden. \citep[chapter 15]{CadleAndYeaters} 

\subsection{Risikoanalyse}
Nedenfor ses risikoanalysen udført på vores projekt. Hver eneste risiko er delt op i ovennævnte punkter for god overskuelighed.
\\\\
\textbf{Risici:} Tidsplanen skrider.\\
\textbf{Effekt/Impact:} Vi risikerer ikke at aflevere til tiden.\\ 
\textbf{Løsning:} Vi bruger SCRUM og opdaterer løbende vores sprint backlog så vi kan se på vores burndown chart om vi holder tidsplanen.\\
\textbf{Overvågning:} Burndown chart\\
\textbf{Skadekontrol:} Identificer grunden til at tidsplanen skrider, og find i plenum en mulig løsning.\\
Etc. hvis der har været sygdom, planlæg hvornår det tabte arbejde kan indhentes.
\\\\
\textbf{Risici:} Estimeringerne holder ikke.\\
\textbf{Effekt/Impact:} Vi risikerer ikke at aflevere til tiden.\\
\textbf{Løsning:} Lav god forundersøgelse af et sprint item før der estimeres, så man undgår at estimeringen bliver helt forkert.\\
\textbf{Overvågning:} Burndown chart. Brug review og retrospektiv til at vurdere om estimeringerne er valide.\\
\textbf{Skadekontrol:} Sæt mere tid af til estimeringer + research.
\\\\
\textbf{Risici:} Serveren går ned så vi ikke kan teste vores services\\
\textbf{Effekt/Impact:} Udvikling og testing går i stå. Kan forsinke projektet.\\
\textbf{Løsning: }Hvis serveren er nede kontaktes vejlederen straks så den hurtigt kan komme op at køre igen.
\\\\
\textbf{Risici:} Forholdsvis lidt erfaring med teknologien.\\
\textbf{Effekt/Impact:} Vi risikerer at løbe ind i problemer og at ting tager længere tid end estimeret.\\
\textbf{Løsning:} Estimer med en vis fejlmargin så der tages højde for at problemer kan opstå.\\
\textbf{Overvågning:} Holdmedlemmer sørger for at indrapportere problemer, ved daily SCRUM.\\
\textbf{Skadekontrol:} Research.
\\\\
\textbf{Risici:} Krav ændres sent i projektet.\\
\textbf{Effekt/Impact:} Vi risikerer at skulle lave om på meget af den kode vi har lavet. Tidsplanen skrider grundet ændringer i koden. Samarbejdet bliver presset.\\
\textbf{Løsning:} Ved projektstart, bør der bruges tid med Singapore, for at få en fælles forståelse for projektet og dets retning. Dette vil medvirke til begge parter har en god ide om  hvad der  skal laves, hvilket minimere sandsynligheden for ændringer og kravs opstandelse i projektets slutning.\\
\textbf{Overvågning:} Have 2 ugentlige møder med Singapore, for at afklare eventuelle misforståelse.\\
\textbf{Skadekontrol:} Så vidt muligt afhjælpe problemet, dog med undtagelser.

\newpage
\subsection{Risikovurdering}

Når en række risici er blevet identificeret, er det oftest svært at tage stilling til hvilke risici der er de vigtigste at kontrollere. Vi har lavet en risikovurdering af de identificerede risici fra analysen ved hjælp af en risikotabel (Se appendix A - Risiko-tabel). Formålet med risiko-tabellen er, at kunne lave en prioritetsliste over de identificerede risici.\\
I tabellen angives for hver risiko, risikoens omfang, timing og omkostninger. For at kunne sortere risici efter prioritet, angives sandsynligheden (Probability/P) for skadevirkningen/impact (C) og den endelige risiko-eksponering (RE).

\begin{itemize}
\item Sandsynligheden angives på en skala fra 0.0 til 1.0.
\item Skadevirkningen angives som et tal mellem 1 og 5.
\end{itemize}

Den endelige risiko-eksponering beregnes ved at gange sandsynligheden med skadevirkningen:
     \begin{center} RE = P * C. \end{center}
Listen sorteres efter risiko-eksponeringen som risikoen bør prioriteres efter.\citep{risikoSlides} 
Vores tabel viser at den mest omfattende risiko for vores projekt ville være en sen ændring i kravspecifikationen, imens serverproblemer ikke vil have store konsekvenser for projektet.
Ud fra denne vurdering har vi valgt at bruge ekstra tid på at forhindre risici med høj RE i forhold til risici med lav RE.

\subsection{Generel skadekontrol}

Skulle der alligevel opstå situationer i projektet, der ikke er taget højde for i risikoanalysen, er det vigtigt at kunne håndtere situationen ordentligt. SCRUM og dets værktøjer fungerer for os som en generel skadekontrol da vi altid har et overblik over hvad hvert gruppemedlem arbejder på. Dette giver os mulighed for at flytte ressourcer for at få løst et problem. 
\newpage